inamerrata

Continuing the darcs theme, it does seem to be fairly pleasant to actually use. Having darcs record go through and prompt you for each change (which you can avoid by saying -a) makes for interesting habits — I’m finding I’m much more inclined to commit once per feature addition, and when I happen to fix a bug while implementing a feature I’m actually feeling encouraged to commit the two changes separately. For similar reasons it seems like a good match for refactoring, which encourages you to make a sequence of small, independent, and trivially correct as you hack.

The ability to just copy the _darcs/ directory to another code tree is pleasant — it really does make it feel like the code you’re working on and the repository you’re working against are separate, independent things which seems sensible and appropriate; and the ability to make an unpacked source tarball suddenly be version controlled, whether it’s had additional modifications or not, is definitely a feature.

On the downside, darcs and nvi don’t cooperate — apparently you have to specifically tell nvi its IO is coming from /dev/tty for it to not die. Oh well. vim, emacs and nano work; and the only reason to use an editor at all is for long log messages, which I’ve only actually wanted once so far — all my other changes have been granular enough to be properly described with a single line. Interestingly, Martin’s librsync darcs hacking seems to be similar, with only about 4% of his changes having more than just the single line description.

I haven’t bothered with patch dependencies yet, which is arguably buggy on my behalf. Not sure how much I should care about that — presumably it’ll become obvious with more use.